docs: Add project-level import/export specification#7114
docs: Add project-level import/export specification#7114
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code review is billed via overage credits. To resume reviews, an organization admin can raise the monthly limit at claude.ai/admin-settings/claude-code.
Once credits are available, reopen this pull request to trigger a review.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
2 Skipped Deployments
|
Prettier was mangling `{/* */}` into `{/_ _/}` which Docusaurus
interprets as a regex literal, breaking the build.
beep boop
- Wrap excluded data list in caution admonition - Add "How entities are matched" section (by name, not ID) - Add permission requirements (project admin for export, org admin for import) - Remove backward-compatibility claim for env-level format in project import beep boop
Remove custom fields/metadata and integration configurations from the optional export data table. Neither has schema or serializer support defined yet. Can be added as follow-up issues. beep boop
| - **[Environment-level](#environment-level-export)**: export and import default feature states for a single environment. | ||
| Useful for quickly copying feature values between environments or projects. | ||
| - **[Project-level](#project-level-export)**: export and import an entire project's feature configuration, including | ||
| segments, segment overrides, and optionally identity overrides and tags. Useful for cloning a project or migrating | ||
| between Flagsmith instances. |
There was a problem hiding this comment.
While I think we can get away with this separation, it's not 100% correct I don't think.
What we're terming the 'Environment-level' import here does include information from the project. It was built as a 'Feature' export, so it includes information about the default value of the flag. As I understand it, this is what is used in a destructive import - it will overwrite other environments with the default value.
Perhaps the scope of this documentation update also covers reviewing and improving the 'Environment-level' import if we can, since this behaviour is not desirable anyway...
| ## Importing | ||
| ## Project-level export | ||
|
|
||
| <!-- TODO: confirm plan availability --> |
There was a problem hiding this comment.
As discussed on the standup, we agreed to keep this available on all plans.
| instances. Specifically: | ||
|
|
||
| Since a feature may have an identical name, it is important to carefully select a merge strategy during a feature import. | ||
| - Features and segments are matched by name. |
There was a problem hiding this comment.
We should be careful here - I have a feeling we don't enforce unique segment names?
2 participants
docs/if required so people know about the feature.Changes
Contributes to #6761
In this PR, we document the planned project-scoped export/import feature alongside the existing environment-level bulk import/export. This serves as the specification before implementation begins.
Key changes to
bulk-import-and-export.md:import-and-export.mdindex page now references both levels.Preview links
How did you test this code?
Documentation-only change. Verified formatting with
npx prettier --checkand Vercel preview build.